REMARKS 



Claims 1-52 were rejected under 35 U.S.C. Section 102(e) as being anticipated by 
Yamamoto et al. (USPN 6,5535431) (hereinafter referred to simply as "Yamamoto"). 
These rejections are respectfully traversed based on the following reasoning. 

Yamamoto describes a network-based system which includes a host computer, a file 
server, input devices and output devices. (See Figure 1 and Col. 6, lines 33-44.) 

A first program, executing on the host computer, allows a iiser to define a virtual input- 
output device. A flowchart for the first program is given in Yamamoto Figure 8. 
Furthermore, the first program is described in detail in the passage starting at Col. 9, line 
55 and extending through Col. 11, line 49. The first program relies on a graphical user 
interface (GUI) through which the user may define a virtual device including an input 
device and a set of one or more output devices. For example, the user may define a 
virtual copier by specifying a scanner and one or more laser printers as suggested in 
Figures 9 A and 9B. 

The first program starts by sending a request to the file server for the device profiles of 
input devices in the network. (Step SI 1 of Figure 8 and Col. 9, lines 63-67). 

Each device profile specifies information regarding a corresponding one of the input 
devices. For example, Figure 7 illustrates the device profile for an image scanner. The 
scanner profile includes information such as: 

the network address of the scanner; 

the set of transfer protocols that the scanner is configured to use; 
the processing resolution of the scanner; 
the paper sizes supported by the scaimer; and 
the data format used by the scanner. 

If the file server returns a plurality of input device profiles, the user is prompted to select 
one of the input device profiles. (Steps SI 3 and S14 of Figure 8 and Col. 10, lines 2-11). 

Next, the first program sends a request to the file server for the device profiles of output 
devices. (Step 15 of Figure 8). The file server may return a set of output device profiles. 
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The first program searches the output device profiles to determine a subset of the output 
device profiles which are compatible with the input device profile selected by the user. 
(Steps SI 7 and S18 of Figure 8). The profile of an output device is compatible with the 
profile of the input device if the output device is capable of performing data output of the 
image data provided by the input device. (Col. 10, lines 17-22). 

The first program prompts the user to select one or more output device profiles fi-om the 
subset of compatible output device profiles. (S20 of Figure 8). Figure 9A illustrates the 
user's selection of laser printers LP5-3 and PL5-1 to be associated with scanner SCAN5. 
The subset of devices compatible with scanner SCANS are shown in the right side panel 
45 of Figures 9A and 9B. 

Next, the first program forms a transfer path profile for the virtual device defined by the 
selected input profile and the one or more selected output profiles. (Step S21 of Figure 
8). The transfer path profile includes: 

a short textual description naming the fiinction (e.g., "COPY") of the virtual 
device and naming the input and output devices of the virtual device; 

an identifier of the input device; 

a network address of the input device; 

identifiers of each of the output devices; and 

for each of the output devices: 

a network address; 

a tray stage for the destination of paper discharge; 

a transfer protocol; 

a data processing resolution; 

a paper size; and 

a data format. 

The first program sends the transfer path profile to the file server. (Step S22 of Figure 8 
and Col. 11, lines 30-31). 

The file server stores the transfer path profile in recording device 7 together with 
information regarding the virtual input-output device. Figure 1 1 illustrates the format of 
the virtual input-output device information. The virtual input-output device information 
includes: 

an identifier of the virtual device; 
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an identifier of the transfer path protocol sent by the host computer in step S22; 
a user profile; and 

a display comment describing the virtual device. 

This information will be referred to herein as a virtual device information record. 

The first program may be executed repeatedly to create a number of virtual input-output 
devices. (This is implied by the fact that multiple virtual device information records are 
available for selection by the user: Col. 12, lines 1-8.) A given input device may be 
associated with a plurality of the virtual input-output devices. For, example, a scanner 
may be associated with a printer PI as part of a first virtual copier, and associated with 
printers P2 and P3 as part of a second virtual copier. Thus, when the user approaches an 
input device with the intent to use the input device to perform a copying task, the user 
must specify which of the virtual devices he/she wishes to invoke. 

Therefore, a second program, executing on the input device (not the host computer) 
allows the user to specify which of the virtual devices is to be invoked for the copying 
task. This second program is illustrated in the flowchart of Figure 12, and, described in 
the passage starting at Col. 11, line 50 and extending through Col. 12, line 53. 

The second program starts when the user presses a key on the scanner console. (Col. 11, 
lines 54-55). (The scanner console is illustrated in Figure 3.) In response to this user 
input, the scanner sends a request to the file server for any virtual device information 
records that involve the scanner as the input component. (Step S31 of Figure 12, and Col. 
11, lines 55-57). If the file server returns a plurality of such virtual device information 
records, the user is prompted to select one of the records. (Step S33 and S34 of Figure 
12). Next, the scanner sends a request to the file server for the transfer path profile of the 
selected virtual device information record. (Step S35 of Figure 12). Using the 
information contained in the transfer path profile, the scanner establishes a connection to 
the output devices specified in the transfer path profile, sets itself for transferring data to 
the output devices, scans the input image, and transmits the scanned image to the output 
devices. (Steps S37-S42 of Figure 12). 

In contrast, claim 1 recites: 
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"A method for propagating type information for hardware device nodes in a 
graphical program, wherein the method operates in a computer including a display 
screen and a user input device, the method comprising: 

displaying on the display screen of the computer a first hardware device node in 
the graphical program in response to user input, wherein the graphical program 
comprises a plurality of interconnected nodes or icons, wherein the plurality of 
interconnected nodes or icons visually indicate functionality of the graphical 
program; 

associating the first hardware device node with a hardware device; 

displaying on the display screen a second hardware device node in the graphical 
program in response to user input; 

connecting the first hardware device node to the second hardware device node in 
response to user input; 

propagating information from the first hardware device node to the second 
hardware device node, wherein the information specifies the hardware device 
with which the first hardware device node is associated, wherein said propagating 
occurs in response to said connecting the first hardware device node to the second 
hardware device node; 

wherein the graphical program is executable by the computer." 

The Examiner relies on 
Figure 6, 

Col. 9, lines 7-19, and 

Figure 27 A, items "A5F-1", "my digital camera", "engineering fax", 
"muto@cpdc" 

from Yamamoto as evidence for the anticipation of 

"displaying on the display screen of the computer a first hardware device node in 
the graphical program in response to user input, wherein the graphical program 
comprises a pluraUty of interconnected nodes or icons, wherein the plurality of 
interconnected nodes or icons visually indicate functionality of the graphical 
program". 

However, please note that the flowchart illustrated in Yamamoto Figure 6 is not a 
graphical program and does not represent a graphical program. The flowchart does not 
include "a plurality of interconnected nodes or icons " as recited in claim 1. The boxes 
containing text descriptions in the flowchart are not nodes or icons. Furthermore, the 
flowchart is not "executable by a computer" as recited in claim 1 . Yamamoto nowhere 
suggests that the flowchart may be executed. Thus, it is improper to identify the 
flowchart of Yamamoto Figure 6 with the graphical program of claim 1. 
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The passage at Col. 9, lines 7-19 describes how a user may supply data to form a device 
profile for the seamier. (See Figure 7 for the data contents of the scantier device profile.) 
The Examiner appears to be identifying the scanner device profile with the first hardware 
device node of claim 1. Note that this passage never suggests that the scanner device 
profile is a node in a graphical program . Thus, it is improper to identify the scanner 
device profile with the first hardware device node of claim 1 . 

Figures 27A-C illustrates a graphical user interface for specifying a virtual device. (Col. 
21, lines 23-37). Figure 27A illustrates a graphical user interface for specifying an input 
device for the virtual device. The Examiner seems to be suggesting that the displayed 
items "ASF-l", "my digital camera", "engineering fax" and "muto@cpdc" are examples 
of the first hardware device node of claim 1. However, these displayed items are not 
nodes in a graphical program . Yamamoto nowhere suggests that the diagram of Figure 
27A is part of a graphical program or that it may be executed. Thus, the displayed items 
are certainly not examples of the first hardware device node of claim 1. 

The Examiner relies on Figure 9A, item 1 as evidence for the anticipation of "associating 
the first hardware device node with a hardware device" as recited in claim 1. In 
particular, the Examiner states that "The ScanS note is associated with the input image 
scanner device." The ScanS pictogram in Figure 9A represents the scanner device 
profile. However, the ScanS pictogram is not and does not represent a node in a 
graphical program . Thus, it is improper to identify the ScanS pictogram of Figure 9A 
with the first hardware device node of claim 1 . 

Furthermore, note that claim 1 recites displaying the first hardware device node before 
associating the first hardware device node with a hardware device. Yamamoto nowhere 
suggests this feature. The pictograms of Figure 9A and 9B are each dedicated to a unique 
one of the device profiles. There is no suggestion that a pictogram is displayed and then 
associated with a hardware device. 

The Examiner relies on Figure 9A, item 4S (the displayed list on the right side panel) as 
evidence for the anticipation of "displaying on the display screen a second hardware 
device node in the graphical program in response to user input" as recited in claim 1. 
However, as noted above, none of the pictograms shown in Figure 9A are nodes in a 
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graphical program. There is absolutely no suggestion in Yamamoto that the diagram 
shown in Figure 9A could be executed as a program by a computer. 

The Examiner relies on the passage at Col. 3, lines 23-56 as evidence for the anticipation 
of 

"propagating information from the first hardware device node to the second 
hardware device node, wherein the information specifies the hardware device 
with which the first hardware device node is associated, wherein said propagating 
occurs in response to said connecting the first hardware device node to the second 
hardware device node" 

as recited in claim 1 . This passage from Yamamoto refers to the information processing 
device (i.e., the host computer) acquiring and registering virtual device information 
records and also to the input device (e.g., the scanner) acquiring the virtual device 
information records and then directly transferring data to the output device (e.g., a laser 
printer). However, note that the data is being transferred between one device and another 
device in a network, not between one node and another node in a graphical program as 
recited in claim 1 . Furthermore, Yamamoto teaches that the data being transferred from 
the input device to the output device is an image that has been scanned at the input 
device. (See, e.g., step S40 and S41 of Figure 12.) Thus, the data being transferred is not 
information that specifies the input device as recited in claim 1 . 

Applicant assumes that the Examiner is identifying the data directly transferred from the 
input device to the output device (disclosed at Col. 3, lines 38-39 and lines 50-51) as the 
information recited in claim 1. However, AppUcant is not entirely sure since the 
Examiner has not so stated. Clarification is respectfiiUy requested. 

In the passage starting at Col. 11, line 54 and extending through Col. 12, line 20, 
Yamamoto teaches that the scanner requests and receives a transfer path profile from the 
file server after the user has selected a particular virtual device to be invoked. The 
transfer path profile includes information regarding the output devices of the virtual 
device, as shown in Figure 10. However, note that the transfer path profile is not 
propagated from one node to another node in a graphical program as recited in claim 1. 
Thus, it does not make sense to identify the transfer path profile with the information 
being propagated in claim 1 . 
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Furthermore, Yamamoto nowhere teaches or suggests . .propagating information from 
the first hardware device node to the second hardware device node, . . . wherein said 
propagating occurs in response to said connecting the first hardware device node to the 
second hardware device node . . ." as recited in claim 1. 

Thus, claim 1 and its dependents are patentably distinguished over Yamamoto at least for 
the reasons given above. 

Claims 18 and 32 each include features similar to Claim 1. Thus, Claims 18 and 32, and 
their dependents, are patentably distinguished over Yamamoto at least for the reasons 
given above in support of claim 1 . 

Claim 10 recites: 

"A method for performing type checking for a hardware device node in a 
graphical program, wherein the method operates in a computer including a display 
screen, the method comprising: 

displaying on the display screen of the computer a first hardware device node in 
the graphical program in response to user input, wherein the graphical program 
comprises a plurality of interconnected nodes or icons, wherein the plurality of 
interconnected nodes or icons visually indicate fimctionaUty of the graphical 
program; 

associating the first hardware device node with a first hardware device class in 
response to user input; 

selecting a method or property of the first hardware device class for the first 
hardware device node in response to user input; 

changing the first hardware device node to have an association with a second 
hardware device class in response to user input; and 

performing type checking to determine whether the method or property is valid 
for the second hardware device class, in response to said changing the first 
hardware device node to have an association with the second hardware device 
class; 

wherein the graphical program is executable by the computer." 

The Examiner rehes on Figure 6 and Col. 9, lines 7-19 from Yamamoto as evidence for 
the anticipation of "displaying on the display screen of the computer a first hardware 
device node in the graphical program in response to user input" as recited in claim 10. 
This same feature is recited in claim 1, and thus, the arguments given above with respect 
to this feature apply to claim 10 also. 
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The Examiner relies on Figure 9 A as evidence for the anticipation of "associating the first 
hardware device node with a first hardware device class in response to user input" as 
recited in claim 10. In particular, the Examiner states "The Scan 5 note is associated with 
the input devices " (Underlining added). Applicant is not sure if the Examiner meant 
"input devices" in the quoted statement, or, "output devices". Figure 9A shows a 
plurality of output devices but does not show a plurality of input devices. Specifically, it 
is not clear what the Examiner means to identify with the first hardware device class of 
claim 10. Clarification is respectfully requested. 

The pictograms shown in Figure 9A represent device profiles, and thus, the 
corresponding devices. Each pictogram represents a single device, not a hardware device 
class . A list of available output devices for the scanner device is displayed on the right 
side panel of the GUI in Figure 9A. Specific members of this Ust may be selected by the 
user to be associated with the input device as part of a virtual device (such as a virtual 
copier). However, note that these selections in no way relate to associating a hardware 
device node in a graphical program with a hardware device class. The Scan5 pictogram 
is not a hardware device node in a graphical program and the output device pictograms 
are not hardware device classes. 

According to the Applicant's specification, each hardware device class defines a set of 
properties and methods that are valid for that class . Yamamoto nowhere teaches or 
suggests the idea of a hardware device class. The device profiles of Yamamoto describe 
specific hardware devices and are not hardware device classes. 

Applicant notes that the Examiner has not asserted any argument (or pointed to any 
evidence from Yamamoto) regarding "selecting a method or property of the first 
hardware device class for the first hardware device node in response to user input" as 
recited in claim 10, Applicant notes that 

"A claim is anticipated only if each and every element as set forth in the claim is 
found, either expressly or inherently described , in a single prior art reference." 
Verdegaal Bros. v. Union Oil Co. of CaUfomia, 814 F.2d 628, 631, 2 USPQ2d 
1051, 1053 (Fed. Cir. 1987)." (See also MPEP 2131) (Underlining added) 
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Applicant respectfully requests that the Examiner either point to evidence for the 
anticipation of the "selecting" feature, or, remove the 102 rejection of claim 10 (and its 
dependents). 

The Examiner telies on Col. 9, lines 7-19 as evidence for the anticipation of "changing 
the first hardware device node to have an association with a second hardware device class 
in response to user input" as recited in claim 10. Col. 9, lines 7-19 describes how a user 
may supply data to form a device profile for the scanner. This passage does not even 
remotely suggest the idea of changing a node to have an association with a different 
hardware device class as recited in claim 10. The passage is entirely concemed with 
specifying profile data for a single device: the scanner. 

Furthermore, it is important to note that the language " changing the first hardware device 
node to have an association with a second hardware device class" implies that the first 
hardware device node is no longer associated with the first hardware device class after 
said changing. This interpretation is supported in the Applicant's specification at page 
34, line 20: 

"In step 604, the hardware device node may be changed to have an association 
with a second hardware device class. For example, the user may disconnect the 
wire that was originally connected to the hardware device node's refiium input 
terminal and may connect a new wire to the terminal. For example, the new wire 
may originate firom a different hardware device node that is associated with the 
second hardware device class, which may be different than the first hardware 
device class." 

Yamamoto nowhere teaches or suggests a change of association of a graphical program 
node fi-om one device to another, or, from one device class to another. 

It is not clear what element (or set of elements) in Yamamoto the Examiner means to 
identify with the second hardware device class of claim 1. Clarification is respectfiilly 
requested. 

The Examiner rehes on the passage starting at Col. 10, line 37 and extending through 
Col. 11, line 5 as evidence for the anticipation of 

"performing type checking to determine whether the method or property is valid 
for the second hardware device class, in response to said changing the first 
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hardware device node to have an association with the second hardware device 
class" 

as recited in claim 10. This passage from Yamamoto describes how a user may 
manipulate the graphical user interface of Figures 9A and 9B to specify a virtual device 
including an input device and one or more output devices. However, there is no 
suggestion in this passage (or anywhere else in Yamamoto) that type checking is 
performed to determine whether a selected method/property of a first hardware device 
class is valid for a second hardware device class . 

Yamamoto does disclose at Col. 10, Hnes 17-25 that an initial set of output device 
profiles received from the file server may be searched to determine the profiles of output 
devices capable of handling the data from a given input device. This search involves 
among other things determining which of the output devices utilize a data format that is 
consistent with the data format used by the input device, based on their profiles (Col. 10, 
lines 22-25.) Perhaps the Examiner means to identify: 

the Scan5 pictogram of Figure 9 A as the first hardware device node of claim 10; 

the scaimer device profile as the first hardware device class of claim 10; 

the device profile of laser printer LP5-3 as the second hardware class of claim 10; 
and 

the compatibility determination of Col. 10, lines 17-25 with the type checking of 
claim 10. 

However, such identifications would be improper because: 

the pictograms of Figure 9 A are not nodes in a graphical program; 

the device profiles of Yamamoto describe specific hardware devices, and thus, are 
not hardware device classes; 

the compatibility determination described by Yamamoto is performed prior to the 
association of an output device (or output device pictogram) with the ScanS 
pictogram. 
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Yamamoto's compatibility determination is performed prior the user making any 
selections, not in response to changing a first hardware device node to have an 
association with a second hardware device class as recited in claim 10. 

Applicant respectfully submits that, at least for the reasons presented above, Claim 10 
and its dependents are patentably distinguished over Yamamoto. 

Claims 26 and 39 each recite features similar to those recited in Claim 10, and thus, 
Claims 26 and 39, and their dependents, are patentable distinguished over Yamamoto at 
least for the reasons given above in support of claim 10. 

Therefore, removal of the § 102 rejections is respectfiilly requested. 



25 



CONCLUSION 

Applicant submits the application is in condition for allowance, and an early notice to 
that effect is requested. 

If any extensions of time (under 37 C.F.R. § 1.136) are necessary to prevent the above 
referenced appUcation(s) from becoming abandoned, Applicant(s) hereby petition for 
such extensions. If any fees are due, the Commissioner is authorized to charge said fees 
to Meyertons, Hood, Kivlin, Kowert & Goetzel PC Deposit Account No. 50-1505/5150- 
52100/JCH. 

Also enclosed herewith are the following items: 

^ Return Receipt Postcard 

[[] Request for Approval of Drawing Changes 

I I Notice of Change of Address 

r~l Check in the amount of $ for fees ( ). 



□ Other: 



RespectfiiUy submitted, 




Mark K. Brightwell 

Reg. No. 47,446 

AGENT FOR APPLICANT(S) 



Meyertons, Hood, Kivlin, Kowert & Goetzel PC 

P.O. Box 398 

Austin, TX 78767-0398 

Phone: (512) 853-8800 

Date: >3«^L '20^2x05" M KB 
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